Is there a nudge emoji?

I kind of like this, but perhaps we should call it release-candidate-check or rc-checklist or something, as I thought it would actually build julia. You can tell I'm really just wanting to feel involved when the only contribution I make to the discussion is name bikeshedding though. ;)

Well, the cat's out of the bag now...

👍

Another item for the list (from #2539 (comment)): replace github's automatic tarball, which won't work because it's missing the submodules, with one we create from make source-dist

The checklist now includes a build of the documentation. Ref #2501

The checklist now builds, makes tarballs, builds docs, runs tests and doctests, and runs the benchmarks (really just to check that the code is still current). I'm not sure what else can go on the list that can be automated.

I'd like to see even more detail in the list of actions at the end. I feel like we might have written this up before, but I'm not sure. Anyway it should include exactly when to commit, push, tag, and send announcement emails, and anything else like that.

@JeffBezanson I added a few more items to the list, but by far the step with the most magic is step #4 which has it's own DISTRIBUTING.md file to try and help explain it. Much of the canonical wisdom of this process is encoded in the scripts sitting in this repository, and I can comb over DISTRIBUTING.md to make sure the two knowledge sources are in sync, but honestly there's way too much text to cram into this makefile rule, so I think it's better to just punt off to DISTRIBUTING.md for this step. Other than that, I think we're good to go here. I say we merge this, commit back the NEWS.md and doc/helpdb.jl changes, then cut a new RC.

How about we keep the instructions only in DISTRIBUTING.md and the steps for building the release candidate in the Makefile?

The lists refer to totally different things IMO --- this one documents our process for putting out a release, and DISTRIBUTING is about making binary distributions from a given version, or possibly even from an unreleased version.

The Makefile just feels like a strange place to have such a list.

It would be ok to have this documented elsewhere and just have the make target cat it, however I feel it does make sense to put it in a makefile. make release or make release-candidate should contain all relevant information for how to make a release (candidate). If it's not going to be fully automated, then printing instructions for what to do manually is the next best thing.

Added a run of DocCheck.jl and rebased. (Note that this now errors out due to the warnings thrown in #7837)

I'm merging and tagging.

I'm also seeing another regression: Profile.print is showing c locations whether I ask for them or not.

I don't think that's related to this PR. This PR only touched stuff in doc/ and that one Makefile rule.

I know, I'm just saying it here since it might be blocking.

Well, I think we might need to hold off on tagging tonight then and reconvene in the morning.